Comment Uber a optimisé son architecture de journalisation | Silicon

Clément Bohic - Silicon - 27/08
Uber a modernisé sa journalisation, à commencer par celle de son écosystème Spark, avec le compresseur CLP au cœur de la démarche.

À quand l’intégration de CLP avec l’infra de l’équipe observabilité ? Uber ne communique pas d’échéance, mais c’est sur sa feuille de route « journalisation ».

Voilà deux ans, l’entreprise américaine avait évoqué ses travaux en la matière. Plus particulièrement sur la compression des logs… grâce à CLP (Compressed Log Processor). Elle est récemment revenue sur l’extension de cette initiative au-delà de la cible initiale, qui était sa plate-forme Spark.

Au départ, 200 To de logs par jour

Sur la partie Spark, le chantier a consisté à intégrer CLP dans la bibliothèque de journalisation native, à savoir Log4j. Au démarrage du projet, la plate-forme big data exécutait, chaque jour, 250 000 jobs comprenant chacun des centaines de milliers de processus. Le volume quotidien au niveau de verbosité par défaut (INFO) pouvait atteindre 200 To. Uber avait alors limité la durée de conservation à 3 jours. L’allonger à un mois – ce que demandaient beaucoup d’utilisateurs internes – aurait fait exploser la facture. Rien que le stockage HDFS aurait coûté plusieurs millions de dollars par an, selon Uber. Et à une telle échelle, un outil comme Elasticsearch aurait engendré des coûts de matériel et d’exploitation prohibitifs.

À ce moment-là, pour les autres journaux,...
[Courte citation de 8% de l'article original]